Treat empty redirectUri as unset

When config is translated from the existing Supabase auth config, an omitted provider redirect is represented as the empty string (redirect_uri = "" in apps/cli/src/shared/init/project-init.templates.ts:327-328), and the legacy launcher falls back when the string is empty (apps/cli-go/internal/start/start.go:1438-1441). This ?? only falls back for null/undefined, so redirectUri: "" emits GOTRUE_EXTERNAL_<ID>_REDIRECT_URI=; for enabled providers that rely on the default callback, local OAuth sign-in will use a blank callback instead of the derived URL. Please treat "" as unset before emitting the env var.

Useful? React with 👍 / 👎.

Good catch — fixed in 5ee3902. ?? only coalesced null/undefined, so a decoded config's redirect_uri = "" (the TOML surface can't say "absent"; the config package's provider schema defaults the key to "") would have emitted an empty GOTRUE_EXTERNAL_<ID>_REDIRECT_URI, which GoTrue's ValidateOAuth refuses with "missing redirect URI". Empty now falls back to the issuer-derived callback, exactly like start.go, with a test row for the empty-string case.

Omit empty provider URLs

When the existing config surface represents an omitted provider URL as url = "" (apps/cli/src/shared/init/project-init.templates.ts:329-331), the legacy launcher intentionally skips the env var unless it is non-empty (apps/cli-go/internal/start/start.go:1451-1452). This condition emits GOTRUE_EXTERNAL_<ID>_URL= for an empty string, which can override GoTrue's built-in provider defaults (for example GitLab's default URL) and break enabled providers that rely on those defaults. Please only emit the URL when it is non-empty.

Useful? React with 👍 / 👎.

Fixed in 5ee3902, though the failure mode is narrower than described: GoTrue reads an empty external URL as unset — every provider routes it through chooseHost(base, default), which falls back to the built-in default when the value is empty, and an empty-set env var is indistinguishable from an absent one to its config loader — so the empty GOTRUE_EXTERNAL_<ID>_URL= couldn't override GitLab's default. We also went the other way from the suggestion: the var now always emits, empty included, rather than matching start.go's skip-when-empty. This stack spawns native services by extending the parent environment, so omitting the var would let a stray shell GOTRUE_EXTERNAL_<ID>_URL supply the provider URL — the same reason the booleans and allow list already emit at their defaults. Behaviorally identical on the GoTrue side; start.go can afford the skip because its containers never inherit a shell.

Preserve auth external URLs when deriving callbacks

Existing callers can set auth.externalUrl to the Auth URL itself (the public API documents it as “Auth external URL” in packages/stack/README.md:116, and this value is passed through to GoTrue as API_EXTERNAL_URL). In that configuration, e.g. https://api.example.com/auth/v1, this fallback emits GOTRUE_EXTERNAL_GOOGLE_REDIRECT_URI=https://api.example.com/auth/v1/auth/v1/callback, so OAuth providers reject the callback mismatch whenever redirectUri is left unset. Derive from a normalized auth URL, or only append /auth/v1 when the configured value is the API root.

Useful? React with 👍 / 👎.

Fixed in 8aa9ad2, at the root rather than by normalizing: externalUrl was carrying two semantics at once. Its name and README description match the classic CLI's auth.external_url — the with-path URL (GetExternalURL derives <api-root>/auth/v1) — but its default was the bare API root, and it feeds API_EXTERNAL_URL, which GoTrue treats as the with-path auth URL: it's the external host outgoing URLs are built against (middleware's external-host fallback), and loadCustomProvider derives <it>/callback for custom providers. The bare root there was itself a latent defect — the stack's proxy only routes /auth/v1/*, so GoTrue-built absolute URLs pointed at paths the proxy never serves. The field is now pinned to its name: the default gains /auth/v1 and the provider callback derives as ${externalUrl}/callback, start.go's JwtIssuer + "/callback" exactly. Your https://api.example.com/auth/v1 example now yields …/auth/v1/callback, the default-config redirect value is unchanged, and API_EXTERNAL_URL gains the classic-parity value. Sniffing for an existing /auth/v1 suffix would have kept the ambiguity alive.

Require secrets before enabling OAuth providers

When callers rely on the new optional secret field, enabled still defaults to true, so auth: { external: { google: { clientId } } } starts GoTrue with GOTRUE_EXTERNAL_GOOGLE_ENABLED=true and an empty secret. The current auth service used by the stack rejects enabled OAuth providers with an empty secret in ValidateOAuth, so the advertised secretless provider path fails at /authorize; require a secret for enabled providers or avoid enabling them when it is omitted.

Useful? React with 👍 / 👎.

This one matches GoTrue's intended model, so the surface stays as is (with a sharper doc comment in 8aa9ad2): the secretless path isn't /authorize — it's the id-token grant (google one-tap, sign-in with apple), which reads the provider config directly in token_oidc.go and never calls ValidateOAuth, so no secret is needed there. That's also why the config package's own schema exempts exactly apple and google from its enabled-requires-secret check, and the classic CLI emits an empty secret the same way. For flows that do need a secret, GoTrue refuses loudly at /authorize ("missing OAuth secret") — identical to classic behavior. Requiring a secret here would break id-token-only configurations upstream itself supports, and auto-disabling would silently turn off a provider the caller declared; provider-specific validation stays with the config layer (which has it) and GoTrue (which enforces it at request time).